In the computing arts, a trap is an event which may be generated entirely by hardware, for example external interrupts, or may be generated by software, for example calls for operating system services. In general, a trap causes system hardware to make an exception to or change the flow of software. The software flow generally may be redirected to a series of software routines, which are designed to handle the particular event that caused the trap. These software routines are commonly referred to as “traps”, “trap handlers” or “trap tables”, the latter also referring to a collection of individual routines.
Trap events, and processing trap events, are common occurrences on most modern computer systems. As mention previously, traps may be caused by interrupts and operating system requests. Another very common cause of traps is a virtual memory system.
In general, in a virtual memory system, the operating system manages memory as a resource, providing a virtual or idealized view of memory to the non-system level software (for example a user program). In this manner, the user programmer may be isolated from the myriad physical details of the actual memory implementation.
Consequently, when a user program accesses “memory,” the operating system must translate the request from a virtual address to a physical address. Generally, this is performed by processing a trap which looks up the physical address from a given virtual address and typically loads the virtual to physical translation into a Translation Lookaside Buffer, or TLB. This process generates large numbers of traps.
Additionally, in many virtual memory systems, all virtual memory addresses may not directly translate to physical memory. The operating system may present a virtual image of memory that is larger than physical memory. The operating system typically will divide memory, both real and virtual, into pages. Through a process known as paging, the operating system may move virtual pages in and out of real memory, generally storing pages taken out of memory on a storage device, for example a rotating magnetic disk. Consequently, the virtual memory system takes on the complexity of managing virtually unlimited amount of memory, simplifying and enabling user software to use large amounts of memory when necessary.
As a result, a TLB trap may request a page of virtual memory that is not currently in real memory. This is generally referred to as a “page fault.” The response to a TLB miss is typically to suspend the calling process while the operating system pages the virtual page into real memory, and resume the calling process when the virtual page is available in real memory.
As a consequence of all of these traps, trap behavior and performance is critical to overall system performance. It is not unusual for a computer system to generate and process millions of traps per second. Because of the critical nature of trap processing, a great deal of effort has gone in to optimizing the software involved in such processing.
Despite being a fundamental indicator of system behavior, there has historically been very little insight provided into the frequency and cost of machine-specific traps because they pose monitoring difficulties. The lack of insight has been especially acute on microprocessors that handle TLB misses as software traps. The frequency and duration of traps plays a decisive role in the performance of the memory system.
Conventional performance monitoring techniques generally rely on conditional execution. If an indicator is enabled, performance statistics will be gathered, at the cost of some processing overhead. If disabled, the statistics will not be gathered, thereby introducing very little overhead. Because of the critical nature of trap processing and the large number of traps, however, even the minimal overhead of accessing the indicator and making the decision has introduced an unacceptable delay. Consequently, in the conventional art there has not been an acceptable technique to monitor this critical aspect of system performance.